\documentclass{l4proj}

\usepackage{url}
\usepackage{fancyvrb}
\usepackage[final]{pdfpages}
\usepackage{subfigure}
\usepackage{float}
\usepackage{txfonts}





%==============================================================================
% T I T L E
%==============================================================================
\begin{document}
\title{A Weight Management App for Mobile Devices}
\author{Aidan Smeaton}
\date{\today}
\maketitle





%==============================================================================
% A B S T R A C T
%==============================================================================
\begin{abstract}

% Awesome guide on writing abstracts
% http://www.ece.cmu.edu/~koopman/essays/abstract.html

Health and wellbeing are important issues in our daily lives. Obesity is now a major global health issue, and so
effective weight loss management is a growing topic of interest. An Android mobile application, Weight Manager,
has been developed and released to Google Play. It supports users wishing to manage weight loss, by providing
tools for setting goals and targets, recording their progress, finding ideas and inspiration, and communicating
with other like-minded users.

\end{abstract}



    

%==============================================================================
% A C K N O W L E D G E M E N T S
%==============================================================================
\section*{\begin{center}Acknowledgments\end{center}}

I would like to thank my project supervisor, Dr Marilyn McGee-Lennon, for her continual guidance throughout this
project; she has been a pillar of support for me during my final year as an undergraduate. I would also like to
thank Dr Cindy Gray from the Institute of Health and Wellbeing for her valuable help and advice. I am very
grateful to the many generous participants in my studies, for their time and excellent feedback they have given.
I would finally like to give a special mention to my family, friends, fellow students, and lecturers for their
patience, encouragement and enthusiasm this year.





%==============================================================================
% E D   U S E   &   C O N T E N T S
%==============================================================================
\setcounter{page}{0}
\educationalconsent
\setcounter{tocdepth}{1}
\tableofcontents





%==============================================================================
%
% I N T R O D U C T I O N
%
%==============================================================================
\chapter{Introduction}
\label{intro}



%==============================================================================
% A I M S   &   O U T L I N E  
%==============================================================================
\section{Aims and Outline}

The aim of this project is to design a mobile application for weight loss management, based on behavior
modification theories, and following user centered approaches to user interface design and evaluation.
Requirements will be gathered in conjunction with health experts from the Institute of Health and Wellbeing, and
the software will be evaluated with real users to demonstrate its feasibility and suitability as a solution to
the current problem.

The application will be developed for Google's Android mobile phone operating system, and will be deployed
to Google Play (formerly the Android Market) for end users to download and use on their own devices. Ultimately, this project shall deliver an \emph{Android App} which supports users in effective weight loss management.

The following outlines the steps that will be taken to achieve these aims:

{\small\begin{itemize}
\item Gather requirements in conjunction with health experts from the Institute of Health and Wellbeing.
\item Gather requirements based on behavior modification theory, user needs, and existing technology.
\item Iteratively design, implement, and evaluate the Android application.
\item Continually liaise with with health experts and potential end users to arrive the at final product.
\end{itemize}}

Academic aims include learning about development for mobile devices, working closely with key stakeholders, 
researching relevant psychology, and taking a user centered approach to the design and evaluation of software.



%==============================================================================
% M O T I V A T I O N
%==============================================================================
\section{Motivation}
A growing issue in the developed world is the management of health and wellbeing. Factors such as an increasingly
ageing population and strains on public health budgets, have resulted in a gradual shift in the way health and
wellbeing is managed. One key element in this shift is the focus on \emph{prevention}. Methods and tools which
encourage and support management of personal care are critical in this care shift.

The developed world has seen an obesity epidemic. Some areas of Europe, North America, the Middle East, and
Oceania have witnessed obesity rates increase to three times what they were in 1980. Although not limited to the
developed world, some proposed reasons for this are changes in society and behavior patterns. Modernisation has
resulted in lifestyles which require less physical activity (office jobs, automated transport, technology in the
home) and convenient availability of unhealthy foods. It is recognised that weight gain can be attributed to
reduced physical activity and the consumption of energy-dense foods with high levels of saturated fats and sugars.
%link - http://www.who.int/dietphysicalactivity/publications/facts/obesity/en/

Obesity is recognised as a major risk for chronic illnesses such as diabetes, strokes, cancer, hypertension, and cardiovascular disease. With over 1 billion overweight adults in the world, and 300 million of them classified as
clinically obese, it is a major issue for the health community. Interventions and tools for weight loss are big
business, but success rates are low.

Technology can play a significant role in enabling people to manage their own health and wellbeing. Many people
already use websites to browse health advice, and often discuss their health and wellbeing on social networking
websites and forums. In addition, many games developers have exploited the fact health is an issue that people are
taking into their own hands. Popular games include Nintendo's Wii-Fit and Brain Training, as well as dance and
action games for Microsoft's Kinect and Sony's Move.

With these issues in mind, the project is worthwhile because it is relevant; it addresses real life issues,
it will be based in current psychological theories, and will utilise modern technologies. Hopefully, the
final product will be a genuine contender against current applications in the same field. It will be exciting
to have health experts and end users on board to steer the project in a successful direction.



%==============================================================================
% P R E L I M I N A R I E S
%==============================================================================
\section{Preliminaries}



%==============================================================================
% G L O S S A R Y
%==============================================================================
\section{Glossary}




%==============================================================================
%
% P R O J E C T   B A C K G R O U N D
%
%==============================================================================
\chapter{Project Background}
\label{background}
This project's proposal was jointly written by Dr Marilyn McGee-Lennon, and fourth year Computing Science
student Aidan Smeaton. The project intends to create a mobile phone application which is based on current psychology, utilises current mobile technology, and shares successful elements of existing weight loss
interventions.

Weight loss management is a particularly tricky health issue to tackle. Many apps have been introduced to help
people track their weight, count calories, monitor their physical activity etc. However, designing apps to
continually motivate and sustain weight loss management is difficult. It is well acknowledged that part of the
problem is achieving actual \emph{behavior modification}. For example, we can use an app short term, and report
that we would prefer an apple to a cookie, but actually increasing the likelihood that we select the apple at
lunch time instead of the cookie is a different matter. There are several theories supporting behavior
modification, and how these can be harnessed, which are discussed in this chapter.

This chapter also discusses several areas of technology which play an important role in the project's background.
Persuasive technology, technology-based weight management, and the Android mobile operating system are topics
which are discussed in detail. As this project is being conducted in conjunction with the Institute of Health and
Wellbeing, this chapter discusses existing weight loss interventions, and the results from their research on
effective weight loss management.



%==============================================================================
% P S Y C H O L O G Y
%==============================================================================
\section{Psychology}
Previous research has shown that interventions which utilise a behavior change theory are significantly more
effective than those which do not. Each theory attempts to explain behavioral change, the most prevalent being
the ones listed below. A common theme amongst all theories is the important role of self-efficacy, an 
individual's confidence or belief that they can change their behavior.

%==============================================================================
% Reasoned Action / Planned Behavior
%==============================================================================
\subsection{Reasoned Action / Planned Behavior}
The theory of reasoned action (TRA) suggests that an individual's intention of performing a behavior depends on
the individual's attitudes toward the behavior, and the influence of the individual's social environment.

For example, a person can have many attitudes toward exercise (it's good for your health, it takes a long time,
it can get uncomfortable, it can be fun). There can also be several influencing factors in the individual's
social environment (your work colleagues all encourage you to exercise, your partner doesn't enjoy exercise,
magazines encourage exercise). The attitudes are weighted in terms of personal importance, and the social
influences are weighted in terms of how important the individual perceives the person's opinion to be. These
are combined, and an intention is formed. If the intention is positive, the behavior will be performed, otherwise,
it won't.

This theory has been revised and extended into the theory of planned behavior, which takes account for cases when
an individual's negative confidence or control over a behavior outweigh a positive intention, resulting in the
behavior ultimately not being performed.

%==============================================================================
% Social Cognitive Theory
%==============================================================================
\subsection{Social Cognitive Theory}
Social Cognitive Theory is a learning theory which suggests that people learn through observation of
other people's behavior (vicarious learning). This model is usually used to describe how humans learn about
morality, but can extend to how humans change their own behaviors, based on observation. The theory suggests
that effective behavior change can be achieved if an individual can easily relate to the person they wish to
imitate, and they feel competent and able to change their behavior (self-efficacy). The theory has many
applications, including marketing and education.

%==============================================================================
% Transtheoretical Model
%==============================================================================
\subsection{Transtheoretical Model}
The transtheoretical model looks at the process of behavior change in stages. It is specific to health-change
behaviors, assessing how prepared an individual is to perform a healthier behavior. The model provides
strategies to encourage the individual to progress through the stages until the behavior is performed and
maintained, accounting for relapses to previous stages. It suggests that people will move forward when the
benefits of the new behavior appear to outweigh the disadvantages. Like other behavior change theories, there
is also a strong emphasis on self-efficacy. Criticism of this model includes the fact that the stages are
arguably not mutually exclusive, and there is little experimental evidence to link the model with actual
health-change behaviors.



%==============================================================================
% T E C H N O L O G Y
%==============================================================================
\section{Technology}
Technology

%==============================================================================
% Persuasive Technology
%==============================================================================
\subsection{Persuasive Technology}
Building on the theories and methods of experimental psychology and human-computer interaction, persuasive
technology is designed to change the attitudes or behaviors of its users. As the name suggests, it does so
through persuasion and social influence, as opposed to coercion.

%==============================================================================
% Technology-based Weight Management
%==============================================================================
\subsection{Technology-based Weight Management}
Bla

\subsubsection{Mobile Phone Applications}
Bla

\subsubsection{Web Applications}
Bla

%==============================================================================
% Android
%==============================================================================
\subsection{Android}
Android is an operating system for mobile phones and tablets. It is developed by the Open Handset Alliance, which
is a consortium of hardware, software and telecommunications companies led by Google. Android is currently the
best selling smartphone platform, with over 300 million devices in use, and over 850,000 devices activated daily.
%https://plus.google.com/u/0/112599748506977857728/posts/Btey7rJBaLF
%http://techcrunch.com/2011/12/22/android-700000/

The platform encourages third party application development, by providing a comprehensive Software Development
Kit (SDK), as well as tutorials and sample code. Standards and guidelines are available for developers, to ensure
that their apps conform with the \emph{look and feel} of Android. Google Play was launched in March 2012, and
provides an official outlet for third party apps. It is the successor to the Android Market, allowing developers
to host apps, and users to download them to their devices.

Android is relatively new and is growing at a very fast rate. Launched in 2008, over 100,000 apps were
subsequently made available on the Android Market as of 2010, with over 1 billion total downloads. Just one year
later in 2011, the number of applications had risen to 400,000, with over 10 billion total downloads. Substantial
growth has been projected for the foreseeable future, making this a desirable platform to develop for.

%==============================================================================
% - Versions and Device Support
%==============================================================================
\subsubsection{Versions and Device Support}
There are several active versions of Android available, with a wide range of supported devices. Figure 
\ref{fig:background:versions} shows the current distribution of versions, the majority of devices using versions
2.2 or higher. 

\begin{figure}[h]
	\centering
	\includegraphics[width=0.6\textwidth]{figures/background/versions.png}
	\caption{Google Play activity for the two weeks leading up to the 14th March, 2012.}
	\label{fig:background:versions}
\end{figure}

As a developer, it is important to consider which version of Android an app will be developed for as apps are
generally not backwards compatible. Developing for 4.0.3 would allow the use of the latest APIs and libraries,
but the app would only be compatible on 1.2\% of devices. Conversely, developing for version 1.5 would restrict
use to the earliest APIs, but would be available to 100\% of devices.
%http://developer.android.com/resources/articles/backward-compatibility.html

It was decided that the app delivered by this project should be developed for version 2.1, as it would allow the
use of several convenient APIs, while still allowing the app to be available to 98.8\% of devices, which is
believed to be a reasonable compromise.

The devices which run Android range from small mobile phones to widescreen televisions. This app is intended to
be used on phones and tablets only, but there is no limitation on the app being run on a Google TV, for example.
The hardware of these devices can vary in terms of actual screen size and resolution, but also the inclusion of
navigation keys and a physical keyboard. Recent versions of Android have deprecated the use of hardware
navigation keys and keyboard, but have provided robust design patterns for apps to cater for devices lacking
these features. Similarly, there are design patterns for the user interface to scale well on different device
sizes.

%==============================================================================
% - App Development
%==============================================================================
\subsubsection{App Development}
Android apps are written in a dialect of Java which, when compiled, runs on the Dalvik virtual machine (DVM). The
DVM is an integral part of the Android operating system responsible for running all applications. The Android SDK
includes tools to aid the process of developing apps, the majority of which are plug-ins to the Eclipse
integrated development environment. Useful tools, such as a debugger and a log framework, were provided by the
Dalvik Debug Monitor (DDMS), and were used frequently throughout development. 

These tools were used to write, execute, test, and debug the app, with the use of a real Android device. The
chosen device to work with was the Samsung Galaxy S2 running on version 2.3 of Android. This was because it is a
modern model (released in 2011), with superior display (Super AMOLED Plus capacitive touchscreen), and includes
useful features such as a high quality camera and support for external storage. Although it wasn't initially 
certain which features the final app would require, use of a camera and external storage were not ruled out.
% TODO move to external storage

%==============================================================================
% - Model View Controller Pattern
%==============================================================================
\subsubsection{Model View Controller Pattern}
Android supports the Model View Controller (MVC) architectural design pattern for the implementation of apps.
MVC encourages the clean separation of the presentation (view) from the data model (model) it represents. The
controller is the code which responds to user interaction with the view, and may manipulate the model accordingly.

\begin{table}[!ht]
	\begin{center}
	\begin{tabular}{| c | c | c |}
		\hline
		{\bf Model} & {\bf View} & {\bf Controller} \\ \hline
		Relational databases & Layout specifications & Activities \\
		Shared Preferences & Drawables & Services \\
		Internal storage & Strings and colours & \\
		External storage & Animations & \\
		Network storage & &  \\ \hline
	\end{tabular}
	\caption{Components of Android applications which fit the MVC pattern.}
	\label{table:background:mvc}
	\end{center}
\end{table}

The data model is typically implemented as an $SQLite$ \emph{relational database}, however persistent primitive
data can be stored easily using \emph{shared preferences}. \emph{Internal storage} can be used to store private
data on the device memory, and \emph{external storage} can be used to store public data on shared external storage
such as a removable SD card. Apps can also access \emph{network storage}, such as data on a web server.
% TODO implementation issue world readable data 

The view is typically represented using a combination of \emph{resources}. Resources include \emph{layout
specifications} which are marked-up in $XML$. These define the positions and attributes of widgets, GUI elements,
and nested layouts. \emph{Drawables} are resources which represent an image or shape, and are typically either a
$.png$ or $.jpg$ image, but can also be defined in $XML$. \emph{Strings}, \emph{colours} and \emph{animations}
are defined in $XML$.

The controller is typically implemented with \emph{Activities}, and occasionally \emph{Services}. Both are
implemented as $.java$ classes which display the view to the user, and respond to user interaction events. They
can access the data model to manipulate the underlying data.

%==============================================================================
% E X I S T I N G   I N T E R V E N T I O N S
%==============================================================================
\section{Existing Interventions}
Applications which already exist, which claim to be effective at aiding weight management.

%==============================================================================
% Football Fans In Training
%==============================================================================
\subsection{Football Fans In Training}
Specific details about Cindy Gray's intervention.





%==============================================================================
%
% S O F T W A R E   D E V E L O P M E N T   P R O C E S S
%
%==============================================================================
\chapter{Software Development Process}
\label{process}
The process of development generally followed the Waterfall approach, where several iterations of development
occurred before ending with the final application. The third iteration followed a more agile approach, with
several very short \emph{sub}-iterations. This chapter will briefly describe each stage in \emph{chronological}
order, and describe how the rest of this report is structured.

This chapter should be a reference for clarifying the order of work carried out. Figure \ref{fig:process:process}
shows the 4 iterations. Each stage has been given its own ID, and may be referred to in later sections of this
report. The stages noted are \textbf{A}nalysis, \textbf{D}esign, \textbf{I}mplementation, \textbf{V}ersion of Implementation, and \textbf{E}valuation/Testing.

First iteration.
\begin{itemize}
\item \textbf{A1} Initial requirements gathering.
\item \textbf{D1} Initial system architecture design, paper prototyping and storyboarding.
\item \textbf{I1} Low fidelity prototype implementation.
\item \textbf{V1} First prototype with minimal functionality (Profile).
\item \textbf{E1} First walkthrough evaluation with health expert.
\end{itemize}

Second iteration.
\begin{itemize}
\item \textbf{D2} Detailed architecture design, further paper prototyping and storyboarding.
\item \textbf{I2} High fidelity prototype implementation.
\item \textbf{V2} Second prototype with functionality (Profile and Diary).
\item \textbf{E2} Co-design sessions with potential end users.
\end{itemize}

Third iteration.
\begin{itemize}
\item \textbf{D3.1}-\textbf{D3.4} Architecture and UI designs, particularly for web services.
\item \textbf{I3.1}-\textbf{I3.4} Implementation of web features, bug fixes, and other updates.
\item \textbf{V3.1}-\textbf{V3.4} Continually updated beta version, available on Google Play.
\item \textbf{E3} Week long summative user evaluation, with 4 short two-day iterations for updates.
\end{itemize}

Fourth iteration.
\begin{itemize}
\item \textbf{D4} Design of lower priority perfective features.
\item \textbf{I4} Implementation of lower priority perfective features.
\item \textbf{V4} Release version, uploaded to Google Play for end users to download. 
\end{itemize}

\begin{figure}[h]
	\centering
	\includegraphics[width=0.95\textwidth]{figures/process/process.png}
	\caption{Process diagram, showing the iterations, with the order and ID of each stage.}
	\label{fig:process:process}
\end{figure}

The remaining chapters of the report will not always be in chronological order due to the iterative nature of
development. For example, design aspects of the final version may be included in Chapter \ref{sys_design} (System
Design), which proceed the results from the first evaluation which may be included in Chapter \ref{eval}
(Evaluation and Testing), despite occurring later in the project lifecycle. The IDs of each stage will be used
where possible for clarity.

\begin{itemize}
\item \textbf{Chapter~\ref{reqs}} (Requirements) discusses the variety of methods used to elicit functional and
non-functional requirements for the intended system. This includes investigations into existing research
and artefacts, and the results from expert interviews and a user questionnaire.
\item \textbf{Chapter~\ref{sys_design}} (System Design) discusses the high level design of the system. This
includes the overall system architecture and data models designed to fulfill the requirements.
\item \textbf{Chapter~\ref{ui_design}} (User Interface Design) discusses how the functional requirements were
fulfilled through considered design of the user interface. Effective UI design for mobile phones is challenging,
and is one of the major factors when considering the usability of the end application. Issues such as utilising
limited screen space, effective use of colour, iconography, typography, and multimodality are considered in this
chapter.
\item \textbf{Chapter~\ref{impl}} (Implementation) discusses how the designs were realised. This includes
discussion of the technologies used and the reasons for choosing them, plus the challenges faced and how they
were addressed.
\item \textbf{Chapter~\ref{eval}} (Evaluation and Testing) discusses how the implementations were evaluated with
our health expert and potential end users. It discusses the formative co-design evaluation, as well as the week
long summative beta-testing stage. This chapter also discusses how the software was verified and validated. 
\end{itemize}





%==============================================================================
%
% R E Q U I R E M E N T S
%
%==============================================================================
\chapter{Requirements}
\label{reqs}



%==============================================================================
% I N T R O D U C T I O N   T O   R E Q U I R E M E N T S
%==============================================================================
\section{Introduction To Requirements}
This chapter discusses the initial stage of the software engineering process for this project, the variety of
ways in which the requirements were elicited. The requirements are essential in building the foundations for any
software engineering project, as they provide a specification which can be used to begin designing a solution to
the problem. They can also be used upon project completion, to check if the final product is satisfactory in
meeting its needs.

There are many stakeholders in this project, as shown in Figure \ref{fig:reqs:stakeholders}. The project proposal was co-written by Marilyn McGee-Lennon (the project supervisor), and Aidan Smeaton (the student carrying out the
project). Other stakeholders include a member of the Institute of Health and Wellbeing, a health expert with
relevant experience in the field of weight management interventions, Cindy Gray. There are also respondents
to a questionnaire conducted during the requirements capture stage, participants who helped evaluate the
application at several stages, and end users who download the app from the Android Market.

\begin{figure}[h]
	\centering
	\includegraphics[width=0.5\textwidth]{figures/reqs/stakeholders.png}
	\caption{A stakeholder map, showing the people related to the project's development.}
	\label{fig:reqs:stakeholders}
\end{figure}

The requirements were elicited by investigating the literature on relevant subjects, and speaking to experts
and potential end-users. The four main processes were as follows:
\begin{itemize}
	\item Researching the fields of weight management, persuasive and mobile technology.
	\item Investigating existing weight management interventions.
	\item Conducting interviews with health experts.
	\item Conducting a questionnaire with potential end users.
\end{itemize}



%==============================================================================
% I N V E S T I G A T I O N   O F   P R E V I O U S   R E S E A R C H
%==============================================================================
\section{Investigation of Previous Research}
Bla...



%==============================================================================
% I N V E S T I G A T I O N   O F   E X I S T I N G   I N T E R V E N T I O N S
%==============================================================================
\section{Investigation of Existing Interventions}

\subsection{Noom}
\label{rq:noom}
For example, to record a BLT, the user would record its components; 2 slices of bread, bacon, lettuce, tomato and
mayo. To estimate the number of calories, each ingredient has an associated colour (green, yellow or red) and
portion size (tiny, small, medium or large).

%==============================================================================
% E X P E R T   I N T E R V I E W S
%==============================================================================
\section{Expert Interviews}
Bla...



%==============================================================================
% U S E R   Q U E S T I O N N A I R E
%==============================================================================
\section{User Questionnaire}
\ref{req:uq}



%==============================================================================
% Overview
%==============================================================================
\subsection{Overview}
To gain insight into potential end users' attitudes towards weight loss management, a set of research questions
were devised. An online questionnaire was then designed and deployed, and the results were collected and 
analysed.



%==============================================================================
% Research Questions
%==============================================================================
\subsection{Research Questions}
To maximise the usability of the application, several research questions were proposed, which the questionnaire
was designed to answer. The questions generally relate to usability aspects of the intended software, as opposed
to proven methods of weight loss, which have already been answered by the literature. For example, the literature
recommends that food intake and exercise output should be recorded for successful weight management; it does not clarify how this should be done. The answers to the research questions should clarify similar issues.

The research questions were as follows:
\begin{enumerate}
	\item Do people actually \emph{want} to lose weight, and if so, \emph{how much} weight do they wish to
lose?
	\item What do people \emph{believe} are the reasons for their successful/unsuccessful weight management?
	\item What \emph{terminology} do people use when discussing how much weight they wish to lose? (For example, stones, pounds, kilos, comfort, dress size, relative, absolute).
	\item How \emph{helpful} do people believe the following techniques would be in successful weight management?
	\begin{itemize}
		\item Recording weight.
		\item Recording mood.
		\item Recording appearance (photographs).
		\item Recording food intake (food diary vs. calorie/portion counting).
		\item Recording exercise (exercise diary vs. energy burn counting / pedometer).
		\item Setting targets (long and short term).
		\item Competition.
		\item Rewarding targets being met, or competitions being `won'.
		\item Having a timed weight loss plan in place (vs. a permanent lifestyle change).
		\item Access to information, inspiration and ideas.
		\item Being reminded of the benefits of weight management.
	\end{itemize}
	\item For each of the listed techniques, how successful do people believe they would be if undertaken
as an individual, a pair, a small group, or a large group?
	\item Do people believe it would be helpful to use a mobile phone with any of the mentioned techniques?
	\item How often would people like to record the following:
	\begin{itemize}
		\item Their weight.
		\item Their food intake.
		\item Their exercise.
	\end{itemize}
	\item What \emph{terminology} would people like to use when recording weight, food and exercise?
	\item How often would people like to do the following:
	\begin{itemize}
		\item Set goals.
		\item Receive feedback of weight loss progress.
		\item Receive reminders.
	\end{itemize}
	\item Would people like to share their weight loss progress with other people? If so, what would they
share, and with whom would they share it?
	\item Do people, who have experience using technology as a weight loss intervention, have any comments
on how it could be improved upon?
	\item How helpful to do people feel using a mobile phone app would be in aiding weight loss?
	\item Are there any significant differences in people's attitudes in terms of gender, age, socio-economic
status, weight, eating habits, fitness, and BMI?
\end{enumerate}



%==============================================================================
% Design and Deployment
%==============================================================================
\subsection{Design and Deployment}
The questionnaire was 

There were 92 participants in total.



%==============================================================================
% Results
%==============================================================================
\subsection{Results}
There were 92 participants in total, 70\% of which completed the questionnaire without skipping any questions.

\begin{enumerate}
	\item Do people actually \emph{want} to lose weight, and if so, \emph{how much} weight do they wish to
lose?

	People do want to lose weight.
	\begin{itemize}
		\item 75.3\% said either \emph{yes} or \emph{maybe}.
	\end{itemize}	

	*need to look into how much they'd like to lose*
	\begin{itemize}
		\item *stats on that*.
	\end{itemize}	

	\item What do people \emph{believe} are the reasons for their successful/unsuccessful weight management?

	People generally recognise it is an \textbf{exercise} issue.
	\begin{itemize}
		\item 28\% mention the key word \emph{exercise}.
		\item 9\% mention the key word \emph{gym}.
	\end{itemize}
	People generally recognise it is an \textbf{eating} issue.
	\begin{itemize}
		\item 21\% mention the key words \emph{food} or \emph{eat}.
		\item 8\% mention the key words \emph{chocolate} or \emph{sweet}.
	\end{itemize}
	Some people believe it is a \textbf{lifestyle} issue.
	\begin{itemize}
		\item 14\% mention the key word \emph{time}.
		\item 3\% mention the key phrase \emph{busy lifestyle}.
	\end{itemize}
	Some people believe it is a \textbf{motivation} issue.
	\begin{itemize}
		\item 9\% mention the key word \emph{motivation}.
		\item 9\% mention the key word \emph{willpower}.
		\item 7\% mention the key word \emph{laziness}.
	\end{itemize}

	\item What \emph{terminology} do people use when discussing how much weight they wish to lose?
	\begin{itemize}
		\item 66\% use British \emph{Imperial units} (stones and pounds).
		\item 10\% use \emph{dress sizes}.
	\end{itemize}

	\item How \emph{helpful} do people believe the following techniques would be in successful weight management?

	Need to do proper statistical analysis on this data.

	\item *several other questions*

\end{enumerate}





%==============================================================================
% S C E N A R I O S
%==============================================================================
\section{Scenarios}
Bla...



%==============================================================================
% F U N C T I O N A L   R E Q U I R E M E N T S
%==============================================================================
\section{Functional Requirements}
\ref{reqs:fr}
Following the requirements elicitation, a final collection of use cases and functional requirements were devised.
These were collated by weighing all previously gathered requirements, extracting those which could be classified
as \emph{functional}, and prioritising them based on effectiveness and feasibility.

The requirements are from the users' perspective, as opposed to the system's. The reason for this is to cleanly
separate the requirements from the design; the requirements should not inform any design decisions. This is why each use case maps directly to a functional requirement.

\begin{figure}[H]
	\centering
	\includegraphics[width=0.95\textwidth]{figures/reqs/use_cases.png}
	\caption{Use case diagram, showing the user and the identified use cases.}
	\label{fig:reqs:usecases}
\end{figure}

Figure \ref{fig:reqs:usecases} shows the use case diagram, each use case corresponding to a functional
requirement. Table \ref{table:req:frt} lists each of these functional requirements with its ID, priority, and
page reference to its full description. Table \ref{table:req:frpg} shows a MoSCoW style grid illustrating the
priorities. There are 4 levels of priority; must have (1), should have (2), could have (3), and would like to
have (4). There are 7 functional requirements which the final application must support, the rest are divided into
the other categories. The development of the app will focus on the requirements with the highest priority first, but will endeavour to satisfy as many as possible.

\begin{table}[!ht]
	\begin{center}
	\begin{tabular}{| c | l | l | c |}
		\hline
		{\bf ID} & {\bf Priority} & {\bf Requirement} & {\bf Description} \\ \hline
		{\bf FR1} & 1 & Set up personal profile & pg \pageref{req:fr:1} \\ \hline
		{\bf FR2} & 1 & View personal daily energy requirement & pg \pageref{req:fr:2} \\ \hline
		{\bf FR3} & 1 & Record and review weight & pg \pageref{req:fr:3} \\ \hline
		{\bf FR4} & 1 & Record and review food intake & pg \pageref{req:fr:4} \\ \hline
		{\bf FR5} & 1 & Record and review exercise & pg \pageref{req:fr:5} \\ \hline
		{\bf FR6} & 2 & Record and review mood and comments & pg \pageref{req:fr:6} \\ \hline
		{\bf FR7} & 4 & Record and review body photos & pg \pageref{req:fr:7} \\ \hline
		{\bf FR8} & 1 & Set and review long term target & pg \pageref{req:fr:8} \\ \hline
		{\bf FR9} & 1 & Set and review short term goals & pg \pageref{req:fr:9} \\ \hline
		{\bf FR10} & 4 & Propose goals for other users & pg \pageref{req:fr:10} \\ \hline
		{\bf FR11} & 4 & Accept/reject proposed goals & pg \pageref{req:fr:11} \\ \hline
		{\bf FR12} & 2 & Plan exercise time in advance & pg \pageref{req:fr:12} \\ \hline
		{\bf FR13} & 2 & Plan meals in advance & pg \pageref{req:fr:13} \\ \hline
		{\bf FR14} & 2 & View rewards when targets or goals are met & pg \pageref{req:fr:14} \\ \hline
		{\bf FR15} & 2 & Set and view multimodal reminders & pg \pageref{req:fr:15} \\ \hline
		{\bf FR16} & 2 & View encouragement and inspiration & pg \pageref{req:fr:16} \\ \hline
		{\bf FR17} & 3 & View alternative eating and exercise ideas & pg \pageref{req:fr:17} \\ \hline
		{\bf FR18} & 3 & Share and view data with select friends & pg \pageref{req:fr:18} \\ \hline
		{\bf FR19} & 3 & Personalise aspects of recording, viewing and sharing & pg \pageref{req:fr:19} \\ \hline
	\end{tabular}
	\caption{Functional requirements of the intended application.}
	\label{table:req:frt}
	\end{center}
\end{table}

\begin{table}[!ht]
	\begin{center}
	\begin{tabular}{| l | l |}
		\hline
		{\bf 1. Must Have} & {\bf 2. Should Have} \\ \hline
		Set up personal profile & Record and review mood and comments \\
		View personal daily energy requirement & Plan exercise time in advance \\
		Record and review weight & Plan meals in advance \\
		Record and review food intake & Set and view multimodal reminders \\
		Record and review exercise & View encouragement and inspiration \\
		Set and review long term target & View rewards when targets or goals are met \\
		Set and review short term goals &  \\ \hline
		{\bf 3. Could Have} & {\bf 4. Would Like To Have} \\ \hline
		View alternative eating and exercise ideas & Propose goals for other users \\
		Share and view data with select friends & Accept/reject proposed goals \\
		Personalise recording, viewing and sharing & Record and review body photos \\ \hline
	\end{tabular}
	\caption{Functional requirements priority grid.}
	\label{table:req:frpg}
	\end{center}
\end{table}


%==============================================================================
% Collating Results
%==============================================================================
\subsection{Collating Results}
How functional requirements were chosen and prioritised, based on effectiveness and feasibility.



%==============================================================================
% Descriptions and Details
%==============================================================================
\subsection{Descriptions and Details}
\label{req:fr}

%
% FR1
%
\subsubsection{FR1: Set up personal profile}
\label{req:fr:1}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to enter their personal details, such as name, age, and weight.
	
	\item[Rationale] \hfill \\
		As the user will be embarking on a weight loss programme, which is a personal issue, it is
		important the user is personally invested in the app.

	\item[Scenarios] \hfill \\
		Use of this feature is demonstrated in Scenario foo
		(Section \ref{req:scenarios:1}).

	\item[Priority] \hfill \\
		1 (must have).
\end{description}

%
% FR2
%
\subsubsection{FR2: View personal daily energy requirement}
\label{req:fr:2}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to calculate their recommended daily energy requirement.
	
	\item[Rationale] \hfill \\
		A person's daily energy requirement can be calculated using information such as their age,
		gender, weight, and current activity level. User's who know their recommended daily energy
		requirement for weight loss can structure their eating habits, to stay within the recommended
		level.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		1 (must have).
\end{description}

%
% FR3
%
\subsubsection{FR3: Record and review weight}
\label{req:fr:3}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to record their current weight, and review their weight loss progress.
	
	\item[Rationale] \hfill \\
		By allowing users to track their weight loss over time, users will be able to see if there is a
		pattern or rate to their weight loss.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		1 (must have).
\end{description}

%
% FR4
%
\subsubsection{FR4: Record and review food intake}
\label{req:fr:4}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to record what they eat, and review what they've eaten.
	
	\item[Rationale] \hfill \\
		By allowing users to track what they eat over time, users will be able to spot their eating
		habits, and will be better at estimating the best foods for fulfilling their future energy
		requirements.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		1 (must have).
\end{description}

%
% FR5
%
\subsubsection{FR5: Record and review exercise}
\label{req:fr:5}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to record their work outs, and review their exercise history.
	
	\item[Rationale] \hfill \\
		By allowing users to track how often they exercise, users will be able to review how well their
		exercise is paying off. By keeping a history of all workouts, users can keep themselves motivated
		by knowing that their hard work has been permanently logged.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		1 (must have).
\end{description}

%
% FR6
%
\subsubsection{FR6: Record and review mood and comments}
\label{req:fr:6}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to record how they feel with regards to their weight loss progress.
	
	\item[Rationale] \hfill \\
		By allowing users to track their emotions and feelings, users can express how the feel about
		their weight loss efforts. By allowing for free-form expression, users will be able to recognise
		what makes them feel a certain way. Users can refer back to how they felt at a previous time.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		2 (should have).
\end{description}

%
% FR7
%
\subsubsection{FR7: Record and review body photos}
\label{req:fr:7}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to record pictures of their body, and review the change over time.
	
	\item[Rationale] \hfill \\
		To give the user a visual representation of their progress, it may be helpful to allow users to
		record pictures of themselves at different stages of their progress. This way, users can monitor
		changes in their physical appearance.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		4 (would like to have).
\end{description}

%
% FR8
%
\subsubsection{FR8: Set and review long term target}
\label{req:fr:8}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to set a long term target for themselves, with a specific date.
	
	\item[Rationale] \hfill \\
		By setting a realistic long term target, the user is giving themselves a definitive end goal to
		strive towards. Users can use this as motivation for their progress, as the ultimate aim of using
		the application and attempting their new weight loss regime is to meet this target.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		1 (must have).
\end{description}

%
% FR9
%
\subsubsection{FR9: Set and review short term goals}
\label{req:fr:9}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to set several short term goals for themselves, which are all specific,
		measurable, achievable, recorded, and time-limited.
	
	\item[Rationale] \hfill \\
		In order to reach the long term target, users need to set stepping stone goals along the way.
		These help make the end target seem more achievable, as these goals should be considerably
		shorter term.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		1 (must have).
\end{description}

%
% FR10
%
\subsubsection{FR10: Propose goals for other users}
\label{req:fr:10}

\begin{description}
	\item[Description] \hfill \\
		As well as setting goals for themselves, users shall be able to propose goals to other users,
		which can either be accepted, or declined.
	
	\item[Rationale] \hfill \\
		In an attempt to motivate users to continually set goals for themselves, users shall be able to
		interact with other users, and challenge other users to achieve similar goals.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		4 (would like to have).
\end{description}

%
% FR11
%
\subsubsection{FR11: Accept/reject proposed goals}
\label{req:fr:11}

\begin{description}
	\item[Description] \hfill \\
		As well as creating goals for themselves, users shall be able to accept goals proposed by other
		users. They should also be able to decline these, or opt out from any form of community based
		goal setting altogether.
	
	\item[Rationale] \hfill \\
		As with \textbf{FR10}, in an attempt to motivate users to continually set goals for themselves,
		users shall be able to interact with other users, and accept or decline goals proposed by other
		users. This would be a form of challenge or competition, which some users may find motivating.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		4 (would like to have).
\end{description}

%
% FR12
%
\subsubsection{FR12: Plan exercise time in advance}
\label{req:fr:12}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to set aside future time for themselves to exercise.
	
	\item[Rationale] \hfill \\
		By allowing users to plan for future exercise, they are more likely to follow it through when the
		time comes. Users can work their exercise routines into their current lifestyle in advance.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		2 (should have).
\end{description}

%
% FR13
%
\subsubsection{FR13: Plan meals in advance}
\label{req:fr:13}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to plan which foods they intend to eat in the future.
	
	\item[Rationale] \hfill \\
		By allowing users to plan their meals, they are more likely to follow it through when the time
		comes, and avoid spontaneous eating. Users can work their meals into their current lifestyle in
		advance.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		2 (should have).
\end{description}

%
% FR14
%
\subsubsection{FR14: View rewards when targets or goals are met}
\label{req:fr:14}

\begin{description}
	\item[Description] \hfill \\
		Users will be notified and rewarded when they have successfully completed their target, or one of
		their goals.
	
	\item[Rationale] \hfill \\
		By keeping a log of successfully completed goals, users can build up achievements. These
		achievements will be motivating, as they visually represent good progress.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		2 (should have).
\end{description}

%
% FR15
%
\subsubsection{FR15: Set and view multimodal reminders}
\label{req:fr:15}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to set themselves reminders for future reference in the form of email, text
		message, Android notification, audio notification, and/or tacton.
	
	\item[Rationale] \hfill \\
		Weight loss interventions which utilise a range of reminder techniques are proven to be more
		effective that those which do not. By allowing users to set reminders for themselves in the
		future, users can predict their own moments of weakness, and prevent them.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		2 (should have).
\end{description}

%
% FR16
%
\subsubsection{FR16: View encouragement and inspiration}
\label{req:fr:16}

\begin{description}
	\item[Description] \hfill \\
		Users shall have access to sources of encouragement and inspiration.
	
	\item[Rationale] \hfill \\
		Results from the user questionnaire suggested that users would benefit from having access to
		encouraging statements, and inspirational stories, as they both contribute to the user's self
		motivation.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		3 (could have).
\end{description}

%
% FR17
%
\subsubsection{FR17: View alternative eating and exercise ideas}
\label{req:fr:17}

\begin{description}
	\item[Description] \hfill \\
		Users shall have access to sources of alternative foods, work-outs, products, and ideas which
		encourage weight loss.
	
	\item[Rationale] \hfill \\
		By presenting a range of ideas to the user, they can explore alternative methods of eating and
		exercising, proposed by other people. This can be helpful, especially if the user feels motivated
		to lose weight, but not motivated enough to explore exactly how they wish to go about it.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		3 (could have).
\end{description}

%
% FR18
%
\subsubsection{FR18: Share and view data with select friends}
\label{req:fr:18}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to share their progress data with other users.
	
	\item[Rationale] \hfill \\
		Users may be encouraged to use the app more if they are able to use it as a social app. By
		allowing users to opt in/out of sharing data with other users, they can publish their progress,
		and compare their progress with other users.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		3 (could have).
\end{description}

%
% FR19
%
\subsubsection{FR19: Personalise aspects of recording, viewing and sharing}
\label{req:fr:19}

\begin{description}
	\item[Description] \hfill \\
		Users shall be able to tailor the app to their own needs, as opposed to being presented with a
		one-app-fits-all. Users shall be able to customise which aspects of the app they have access to,
		and what data is shared with other users.
	
	\item[Rationale] \hfill \\
		By encouraging the user to personalise the app to their own needs, they make the app unique to
		their use, and will become more invested in its use. Software which is personalisable is more
		usable.

	\item[Scenarios] \hfill \\
		Foo.

	\item[Priority] \hfill \\
		3 (could have).
\end{description}



%==============================================================================
% N O N - F U N C T I O N A L   R E Q U I R E M E N T S
%==============================================================================
\section{Non-Functional Requirements}
\ref{reqs:nf}



%==============================================================================
% Non-Functional Requirements Table
%==============================================================================
\subsection{Non-Functional Requirements Table}
The following table lists the final set of non-functional requirements.

\begin{table}[!ht]
	\begin{center}
	\begin{tabular}{| c | l | c |}
		\hline
		{\bf ID} & {\bf Requirement} & {\bf Description} \\ \hline
		{\bf NF1} & Support Android 2.1 onwards & pg \pageref{req:nf:1} \\ \hline
		{\bf NF2} & Run with and without external storage & pg \pageref{req:nf:2} \\ \hline
		{\bf NF3} & Run with and without an Internet connection & pg \pageref{req:nf:3} \\ \hline
		{\bf NF4} & Package as $.apk$ with size less than 5mb & pg \pageref{req:nf:4} \\ \hline
		{\bf NF5} & Support theory of Reasoned Action / Planned Behavior & pg \pageref{req:nf:5} \\ \hline
		{\bf NF6} & Be suitably usable & pg \pageref{req:nf:6} \\ \hline
	\end{tabular}
	\caption{Functional requirements of the intended application.}
	\label{table:req:frt}
	\end{center}
\end{table}




%==============================================================================
% Descriptions and Details
%==============================================================================
\subsection{Descriptions and Details}

%
% NF1
%
\subsubsection{NF1: Support Android 2.1 Onwards}
\label{req:nf:1}
In order to maximise the potential audience for the end application, it is important to maximise the number of
versions of the Android platform supported. Android 2.2 was chosen as it is still widely in use, and offers
benefits over its predecessors (such as SD card support).

%
% NF2
%
\subsubsection{NF2: Run with and without external storage}
\label{req:nf:2}
Many Android users do not wish to store apps on their device's internal storage, and instead wish to store it on
an SD (Secure Digital) card. Other users do not have an SD card, and so have no option but to store apps on their
device's internal storage. The final product should be portable, so that it can be transferred to an SD card on
request, but should also be small enough for cases when there is no alternative storage.

%
% NF3
%
\subsubsection{NF3: Run with and without an Internet connection}
\label{req:nf:3}
Many features of the application will likely require an Internet connection (such as sharing data with friends
\textbf{FR18}). The app should still be usable without an Internet connection, so users still have access to main
functions.

%
% NF4
%
\subsubsection{NF4: Package as $.apk$ with size less than 5mb}
\label{req:nf:4}
Mobile network transfer speeds can be slow, and storage on mobile devices can be limited. The final size of the
application should be minimised to encourage users to download and install it.

%
% NF5
%
\subsubsection{NF5: Support theory of Reasoned Action / Planned Behavior}
\label{req:nf:5}
To maximise the likelihood that behavior change will occur, the app must support the theory of Reasoned Action /
Planned Behavior in all aspects of its use. This will mean that the app must improve confidence in the
individual's ability to lose weight, and allow for them to make the conscious choice that they want to take
action.

%
% NF6
%
\subsubsection{NF6: Be suitably usable}
\label{req:nf:6}
The application must be considered usable by the end-users to be considered a success. There is no point in
having an app which supports all the above requirements, if the potential end-users are not willing to use it.





%==============================================================================
%
% S Y S T E M   D E S I G N
%
%==============================================================================
\chapter{System Design}
\label{sys_design}

%==============================================================================
% I N T R O D U C T I O N   T O   S Y S T E M   D E S I G N
%==============================================================================
\section{Introduction To System Design}
This chapter discusses the high level architecture and design decisions taken to satisfy the requirements.
An overall system architecture was proposed, and a solution to each functional requirement was devised
using components from the overall architecture.



%==============================================================================
% S Y S T E M   A R C H I T E C T U R E
%==============================================================================
\section{System Architecture}
To satisfy the requirements identified in Chapter \ref{reqs}, a system architecture was devised early in the
project lifecycle. As shown in figure \ref{fig:sys_design:architecture}, components were divided into two groups;
local components bundled as part of the app, and remote components accessible via the Internet.

\begin{figure}[h]
	\centering
	\includegraphics[width=0.95\textwidth]{figures/sys_design/architecture.png}
	\caption{Early system architecture design.}
	\label{fig:sys_design:architecture}
\end{figure}

It was important that design decisions didn't inform unnecessary implementation constraints. Non-functional
requirements \textbf{NF1} and \textbf{NF4} require the final implementation to be an Android app, so it was
reasonable to design with this in mind. Components such as \emph{activities}, \emph{resources}, \emph{adapters}
and \emph{assets} are specific to Android, and so may be impossible to implement as an iPhone app, for example.
However, this is acceptable, as the requirements allow for designing solely for Android.

%==============================================================================
% Activites
%==============================================================================
\subsection{Activities}
To satisfy each of the functional requirements, the \emph{activities} component was required. This component
deals with user interaction, and has access to the \emph{data} component. Each of the functional
requirements involves user interaction of some sort, so this is one of the major components.

Activities have sole access to several other smaller components such as \emph{adapters}, which are used to
display lists of data, and \emph{resources} which are collections of user interface components. They also have
access to external libraries and utilities.

%==============================================================================
% Data
%==============================================================================
\subsection{Data}
The \emph{data} component acts as a middleman between the activities and actual data. It has access to data
stored on a local database, external data feeds, and network storage through the remote \emph{middleware}  component.

Functional requirements \textbf{FR3}, \textbf{FR4}, \textbf{FR5}, \textbf{FR6}, \textbf{FR7}, \textbf{FR8} and
\textbf{FR9} (see section \ref{req:fr}) require related data to be stored and queried. A local database would
be the best choice for fulfilling these requirements. A template for the database can be initially stored as an
asset in the \emph{assets} component, and a local database can be created and continually used after the app
is first launched.

Functional requirements \textbf{FR16} and \textbf{FR17} (encouragement, inspiration and ideas) are interesting as
they could be satisfied with features hard-coded into the app (such as encouraging messages like ``Keep it up!'').
However, the user will eventually exhaust the limited supply, making this a rather superficial solution.
A more effective way to fulfill these requirements would be to use third party data feeds, with constantly
refreshing encouragement, inspiration and ideas. Community websites such as $reddit.com$ provide APIs for
developers, and with a wealth of contributors providing fresh content, fulfill these requirements more
substantially.

%==============================================================================
% Middleware
%==============================================================================
\subsection{Middleware}
The \emph{middleware} component hosted on a remote server acts as a middleman between the \emph{data} component
of the app, and actual data stored on the remote server.

Functional requirements \textbf{FR10}, \textbf{FR11} and \textbf{FR18} require an element of social networking.
However, the requirements elicitation found that users would rather share their data with people on a
social network which is private to an existing one (such as Facebook or Twitter). Using existing social networks
could have been done through effective use of their APIs, but creating a new one is a different challenge.

The proposed solution was to host a relational database on a remote server to store and query the content of the
social network. The \emph{middleware} component is visible to the app, and is able to read and write to the
database. It is therefore used as an interface between all instances of the app and the single remote
database.



%==============================================================================
% S A T I S F Y I N G   T H E   F U N C T I O N A L   R E Q S
%==============================================================================
\section{Satisfying The Functional Requirements}
Part of the challenge in satisfying the functional requirements was being able to understand the relationships
between them. Rather than tackle each of the nineteen requirements individually, they were arranged into six
clusters. The app caters for this by having a section dedicated to the functions required by each cluster.
For example, functional requirements \textbf{FR3}, \textbf{FR4}, \textbf{FR5}, \textbf{FR6} and \textbf{FR7}
form the Diary cluster, and so are all implemented in the \emph{Diary} feature of the app. Each cluster and
its components are described below.

\begin{description}
\item[Profile] \hfill \\
	Includes requirements that deal with aspects 
\item[Diary] \hfill \\
\item[External Community] \hfill \\
\item[Internal Community] \hfill \\
\item[Target and Goal Manager] \hfill \\
\item[Planner] \hfill \\
\end{description}


%==============================================================================
% Profile
%==============================================================================
\subsection{Profile}

%==============================================================================
% - FR1: Set up personal profile
%==============================================================================
\subsubsection{FR1: Set up personal profile}
A section of the app should be dedicated to the user's personal profile, and allow them to enter details such
as their first name, age, gender and weight. These values will be stored in \emph{shared preferences}, a
convenient data storage technique employed by Android for persisting primitive data to be accessible from
anywhere in the app.

\begin{description}
    \item[First name] \hfill \\
        An editable text field should be available for the user to enter their name. The soft keyboard should
	be launched if the device has no hardware keyboard, and be set for regular alphanumeric input. The
	value should be stored as a string in the app's shared preferences.
    \item[Age] \hfill \\
        As with the first name, an editable text field should allow the user to enter their age. However, the
	field should only allow numeric input, and the soft keyboard should be defaulted to the number pad.
	The value should be stored as an integer, and input validation should be performed to ensure that the
	user is aged 18 or over.
    \item[Gender] \hfill \\
        Two labeled radio buttons should allow the user to have the exclusive choice between male and female.
	The selection should be stored as a boolean value, true being female (arbitrarily).
    \item[Lifestyle Activity] \hfill \\
        Four labeled radio buttons should allow the user to select from four lifestyle activity options; inactive,
	light, moderate	and heavy. The selection should be stored as an integer (0, 1, 2 or 3).
    \item[Weight] \hfill \\
        As with age, an editable text field should allow the user to enter a numeric weight. Initial designs
	support metric weight, requiring an integer value (a weight in kilograms). However, later designs support
	British Imperial units, and use two fields to get two integers (one for stones and one for pounds).

	Weight is stored as a \emph{weight record} in a local relational database, which is discussed in more
	detail in chapter \ref{sys_design:fr:3}.

\end{description}

%==============================================================================
% - FR2: View personal daily energy requirement
%==============================================================================
\subsubsection{FR2: View personal daily energy requirement}
One fundamental aspect of weight loss management is ensuring that the energy consumed is less than the
energy used by the body. Cindy, the project's health expert, provided calculations for estimating the energy
the body uses per day when the body is idle or sleeping. There are further calculations which take account of
how much exercise the user typically does, to work out the maximum amount of energy the user should consume in
order to achieve weight loss.

Ultimately, a section of the app should be able to calculate the maximum number of calories (energy) a user
can consume per day, based on their personal details (see \textbf{FR1}). The algorithm below does just
that, taking the user's details as parameters, and returning the number of calories. It first calculates the
user's \emph{Basal Metabolic Rate (BMR)}, and multiplies this by the user's \emph{Physical Activity Level (PAL)}
to get the number of calories required for the user to stay their current weight. It then rounds this value to
the nearest 100, and subtracts 600 calories, which is the estimated maximum number of calories required for the
user to achieve weight loss. It finally returns this value, unless it is below 1400 calories (in which case it
returns 1400).

{\small\begin{verbatim}
calculateEnergy(age, weight, isFemale, exercise)
    bmr = calculateBMR(age, weight, isFemale)
    req = bmr * calculatePAL(exercise)
    return Math.max((((req - 600) / 100) * 100), 1400)
\end{verbatim}}

The Basal Metabolic Rate is the amount of daily energy expended by humans at rest. The algorithm below shows
how this value is calculated, based on factors such as age, gender and weight. This algorithm returns -1 if the
age is below 18, as the project is focussed on adult weight loss on ethical grounds.

{\small\begin{verbatim}
calculateBMR(age, weight, isFemale)
    if (age >= 18 && age < 30)
        return (isFemale) ? (weight * 14.7) + 496 : (weight * 15.3) + 679
    else if (age >= 30 && age < 60)
        return (isFemale) ? (weight * 8.7) + 829 : (weight * 11.6) + 879
    else if (age >= 60)
        return (isFemale) ? (weight * 10.5) + 596 : (weight * 13.5) + 487
    else return -1
\end{verbatim}}

The Physical Activity Level is a floating point value used to extend the BMR calculation, to take account of the
energy used when the person is not at rest. It takes the user's claimed daily exercise activity level into
account, and returns a value which is used to augment the estimated number of calories expended per day. As
seen below, higher levels of activity return a higher multiplier, as people who exercise more will burn
more calories.

{\small\begin{verbatim}
calculatePAL(activityLevel)
    switch (activityLevel)
        case INACTIVE:	return 1.3
        case LIGHT:	return 1.55
        case MODERATE:	return 1.78
        case HEAVY:	return 2.1
\end{verbatim}}

%==============================================================================
% - FR19: Personalise aspects of recording, viewing and sharing
%==============================================================================
\subsubsection{FR19: Personalise aspects of recording, viewing and sharing}
Each user should be able to customise the application to suit their personal needs. There should be a section
of the app where the user can change a range of settings such as preferred weight type (metric versus
imperial) and accelerometer sensitivity (for activities that utilise this as an input method).

%==============================================================================
% Diary
%==============================================================================
\subsection{Diary}
A section of the app was designed to fulfill the requirements related to recording and reviewing information.
This \emph{Diary} feature should allow the user to record, review, and remove log entries related to their
weight loss. These log entries can be their actual weight (\textbf{FR3}), food they've eaten (\textbf{FR4}),
exercise they've done (\textbf{FR5}), how they're feeling (\textbf{FR6}), and photos of themselves (\textbf{FR7}).

\begin{figure}[h]
	\centering
	\includegraphics[width=0.95\textwidth]{figures/sys_design/schema_diary.png}
	\caption{ER Diagram for Diary.}
	\label{fig:sys_design:schema_diary}
\end{figure}

As shown in figure \ref{fig:sys_design:schema_diary}, an initial Entity Relationship (ER) Diagram was designed to
accomodate each feature. Most logs can be represented as self contained entities, with no relation to other
entities. However, the food log is composed of several \emph{ingredients}, as discussed in more detail in chapter
\ref{sys_design:fr:4}. Each entity has a primary key, \emph{\_id}, which is conventional for Android.

%==============================================================================
% - FR3: Record and review weight
%==============================================================================
\subsubsection{FR3: Record and review weight}
\label{sys_design:fr:3}
When a user records their weight (e.g. 80 kg), the record has a value (80) and a unit type (metric).
The weight log entity has an attribute for each of these, with an additional \emph{time} attribute for the
time the weight was recorded.

%==============================================================================
% - FR4: Record and review food intake
%==============================================================================
\subsubsection{FR4: Record and review food intake}
\label{sys_design:fr:4}
Recording food is the most complex aspect of the Diary feature, as there are many potential ways users may
wish to do so. Results from the user questionnaire discussed in chapter \ref{req:uq} and shown in figure
\ref{fig:graph:food_diary_techniques} suggest that users generally agreed that calorie tracking or keeping a
food diary would be helpful in aiding weight loss.

\begin{figure}[h]
	\centering
	\includegraphics[width=0.95\textwidth]{figures/graph/food_diary_techniques.png}
	\caption{Results from user questionnaire. Users were asked to rate how helpful they thought
	certain techniques would be in aiding weight loss.}
	\label{fig:graph:food_diary_techniques}
\end{figure}

\begin{figure}[h]
	\centering
	\includegraphics[width=0.95\textwidth]{figures/graph/food_diary_intake.png}
	\caption{Results from user questionnaire. Users were asked how they would like to record their
	food intake.}
	\label{fig:graph:food_diary_intake}
\end{figure}

However, participants were later asked how they would like to record their food intake, as shown in figure
\ref{fig:graph:food_diary_intake}. Despite over 80\% of participants agreeing that calorie tracking would be
helpful in aiding weight loss, less than 50\% of them said that they would like to record their food intake this
way if they were trying to lose weight. Similarly, over 80\% of participants agreed that a food diary would be
helpful in aiding weight loss, yet less than a 35\% of them said that they would like to record their food intake
as meals if they were trying to lose weight.

One of the non-functional requirements of this project was that the final app should be usable (\textbf{NF6}).
As there was no single technique which people unanimously prefered, a method for recording food needed to be
created and evaluated with end users. Inspiration was drawn from exisiting apps and interventions. 

The first idea that was explored was barcode scanning and calorie database lookup. As in existing apps such
as \emph{MyFitnessPal} (see chapter \ref{req:myfitnesspal}, users can scan the barcode of a food item using
their device's camera, and the app suggests how many calories are in the food. After investigating this idea,
it seemed that there was no freely available and reliable barcode lookup service or useful calorie databases.
Many of the databases were simply too large to bundle as part of the application (several megabytes), and most
contained information about American brands only.

The project's health expert, Cindy, suggested using portions instead of calories. The idea is that users can
quantify portions when thinking about food, and portions of certain foods can map directly to calorie values.
This way users can track their calories without actually thinking in terms of calories. An existing app which
uses a similar technique is \emph{Noom}, as discussed in chapter \ref{req:noom}, which allows users to build a
food record composed of ingredients.

\subsubsection{FR5: Record and review exercise }
\subsubsection{FR6: Record and review mood and comments}
\subsubsection{FR7: Record and review body photos}

%==============================================================================
% External Community
%==============================================================================
\subsection{External Community}
A section of the app was designed to utilise features of existing web communities. \textbf{FR16} (View
encouragement and inspiration) and \textbf{FR17} (View alternative eating and exercise ideas) could be satisfied
by allowing the user to access content created by communities.

An investigation was done to locate online communities which have the following qualities:
\begin{itemize}
\item Support a web API.
\item Have a large active user base.
\item Content is substantial.
\item Content is relevant.
\end{itemize}

The web has many active communities dedicated to weight loss management such as $weight-loss.fitness.com$ and
$minimins.com$, however very few of them support third party integration with an API. One popular social news
website which does support developers is $reddit.com$, which has at least 60,000 communities (known as
\emph{subreddits}).



\subsubsection{FR16: View encouragement and inspiration}
\subsubsection{FR17: View alternative eating and exercise ideas}

%==============================================================================
% Internal Community
%==============================================================================
\subsection{Internal Community}

\subsubsection{FR18: Share and view data with select friends}
\subsubsection{FR10: Propose goals for other users}
\subsubsection{FR11: Accept/reject proposed goals}

%==============================================================================
% Target and Goal Manager
%==============================================================================
\subsection{Target and Goal Manager}

\subsubsection{FR8: Set and review long term target}
\subsubsection{FR9: Set and review short term goals}
\subsubsection{FR14: View rewards when targets or goals are met}

%==============================================================================
% Planner
%==============================================================================
\subsection{Planner}

\subsubsection{FR12: Plan exercise time in advance}
\subsubsection{FR13: Plan meals in advance}
\subsubsection{FR15: Set and view multimodal reminders}


%==============================================================================
% S Y S T E M   D E S I G N   I S S U E S
%==============================================================================
\section{System Design Issues}
Bla...





%==============================================================================
%
% U S E R   I N T E R F A C E   D E S I G N
%
%==============================================================================
\chapter{User Interface Design}
\label{ui_design}
The UI design...



%==============================================================================
% I N T R O D U C T I O N   T O   U I   D E S I G N
%==============================================================================
\section{Introduction To User Interface Design}
Intro...



%==============================================================================
% W I R E F R A M E S   A N D   S T O R Y B O A R D S
%==============================================================================
\section{Wireframes And Storyboards}
Bla...



%==============================================================================
% G R A P H I C A L   U S E R   I N T E R F A C E   E L E M E N T S
%==============================================================================
\section{Graphical User Interface Elements}
Bla...



%==============================================================================
% M U L T I M O D A L   U S E R   I N T E R F A C E   E L E M E N T S
%==============================================================================
\section{Multimodal User Interface Elements}
Bla...



%==============================================================================
% D E S I G N   P A T T E R N S
%==============================================================================
\section{Design Patterns}
Android bla...





%==============================================================================
%
% I M P L E M E N T A T I O N
%
%==============================================================================
\chapter{Implementation}
\label{impl}





%==============================================================================
%
% E V A L U A T I O N   A N D   T E S T I N G
%
%==============================================================================
\chapter{Evaluation And Testing}
\label{eval}
As this project's philosophy is user-centered, users are held in high esteem and considered experts in the final
product; they are who the product is intended for. To maximise the usability of the end application
it is essential that designer and user collaborate throughout the project's development. As with the initial
requirements capture stage, the phases of evaluation in this project involve end users and our health
expert stakeholder.

The app was evaluated rigorously with several key stakeholders during each iteration of development. The first
low fidelity implementation (\textbf{I1}) was evaluated with the project's health expert to validate
the software. The second implementation (\textbf{I2}) was used during three co-design workshops, which were
used to evaluate the usability of the app, and also gather possible solutions for redesign. The third
implementation (\textbf{I3}) was evaluated \emph{in the wild} with real users, who used the app for a week
on their own devices, and gave feedback during this time. The release version (\textbf{I4}) was then verified
with our health expert before being made available to the public.
%http://www.pragmaticmarketing.com/publications/magazine/6/2/utilizing-co-design-to-create-market-driven-products

Although evaluation and testing are often distinct, all aspects of the evaluation process could be classified
as testing in this project. The initial validation and final verification stages were performed to ensure
the software meets the requirements and works as expected. This is often associated with testing rather than
evaluation. The co-design workshops and, as the name suggests, the beta testing stage could be classified as testing. This is because they were used to find residual bugs in the code, as well as their primary purposes to
evaluate the app's usability.



%==============================================================================
% S O F T W A R E   V A L I D A T I O N
%==============================================================================
\section{Software Validation}

%==============================================================================
% Aims
%==============================================================================
\subsection{Aims}
After the initial requirements were gathered, a low fidelity prototype was designed and implemented
(\textbf{V1}). Before further work could commence, it was important to validate this prototype with Cindy Gray,
the project's health expert and one of our key stakeholders.

%==============================================================================
% Method
%==============================================================================
\subsection{Methodology}
Early in development, during one of the monthly meetings with Cindy, half an hour was dedicated to this
evaluation. The first step was to confirm that the project's requirements accurately reflected her requirements
as a stakeholder. The second step was to demonstrate a proposed solution, and confirm that this would satisfy the
requirements if fully implemented. The structure of the evaluation is outlined in table
\ref{table:eval:val:outline}.

\begin{table}[!ht]
	\begin{center}
	\begin{tabular}{| p{12cm} | c |}
		\hline
		{\bf Introduction} & 2 mins \\
		The demonstrator explains the evaluation to the health expert, its aims and outline.
		& \\ \hline
		{\bf Verification of the Functional Requirements} & 10 mins \\
		The demonstrator explains the Fuctional Requirements as identified in chapter \ref{reqs:fr}.
		The expert is asked to confirm each of them, allowing for suggestions for change or improvement.
		& \\ \hline
		{\bf Walkthrough with prototype} & 10 mins \\
		The demonstrator explains the currently proposed solution, and demonstrates the low fidelty
		prototype. The expert is asked to validate that the intended software meets the requirements,
		allowing for suggestions for change or improvement. & \\ \hline
		{\bf Debriefing} & 5 mins \\
		The demonstrator explains the next steps in development.
		& \\ \hline
	\end{tabular}
	\caption{Outline of software validation with health expert.}
	\label{table:eval:val:outline}
	\end{center}
\end{table}

%==============================================================================
% Results
%==============================================================================
\subsection{Results}
In general, the requirements were confirmed and the design was validated. However, some of the initial priorities
were renegotiated. \textbf{FR10} (Propose goals for other users) and \textbf{FR11} (Accept/reject proposed goals)
both originally had a priority level of 2 (should have). Cindy felt quite strongly that these requirements were
not as pressing as some of the others, and so it was decided to demote them to priority level 4 (would like to
have). \textbf{FR16} (View encouragement and inspiration) orignally had a priority level of 3 (could have), but
was promoted to level 2 (should have), as Cindy felt that it was a particularly important feature.



%==============================================================================
% C O - D E S I G N   W O R K S H O P S
%==============================================================================
\section{Co-Design Workshops}
\label{eval:cds}

%==============================================================================
% Aims
%==============================================================================
\subsection{Aims}
At the end of the second iteration of development, the \emph{Profile} and \emph{Diary} features of the app
had been implemented in full. Before continuing development in these areas, or beginning work in other areas such as one of the \emph{Community} features, the app was formatively evaluated with potential end users in co-design
sessions.

The purpose was to gain qualitative subjective feedback on the users' experiences with the user interface, to
find out which aspects of the app they: (1) like and would want to keep; (2) like but would want to change in
some way; and (3) dislike and would want removed from the app. The feedback was used to refine the app in the
subsequent iteration.

%==============================================================================
% Method
%==============================================================================
\subsection{Methodology}
12 participants were involved in total, in 3 group sessions (N=4). The sessions were an hour long in closed
rooms with no distractions, and followed the structure outlined in table \ref{table:eval:cds:outline}.
Participants were provided with refreshments, which were also used as part of the evaluation (for photographing
food in the app).

\begin{table}[!ht]
	\begin{center}
	\begin{tabular}{| p{12cm} | c |}
		\hline
		{\bf Briefing} & 5 mins \\
		Users are introduced to the evaluation, its aims and outline.
		& \\ \hline
		{\bf Initial walkthrough with prototype} & 5 mins \\
		The demonstrator explains the purpose of the app, and shows the main features to be evaluated.
		Details are purposefully omitted, as part of the proceeding activity aims to gauge the
		participants' initial reactions to the system.
		& \\ \hline
		{\bf Free will application use} & 10 mins \\
		Participants are split into two pairs and given a notepad, a pen and a device with the app. In
		pairs they are encouraged to explore the app, talk about what they're doing between themselves,
		and note down anything that they particularly liked, disliked, or were unsure of. They are
		encouraged to write things down that they think are useful, clear, cool, confusing, irritating,
		or unnecessary.
		& \\ \hline
		{\bf Group discussion} & 10 mins \\
		The demonstrator mediates a conversation between the four participants about their findings, and
		encourages participants to discuss similarities or differences in opinion.
		& \\ \hline
		{\bf Detailed walkthrough} & 5 mins \\
		The demonstrator explains the details of the app, in particular features that participants
		appeared not to understand properly in the group discussion.
		& \\ \hline
		{\bf Group \emph{Keep/Lose/Change} exercise} & 20 mins \\
		Participants are presented with large paper screenshots of the app, and asked to annotate them
		with adhesive \emph{post-it} notes. Participants are asked to mark features that they like in
		green, dislike in red, and would like to change in orange. For each annotion, participants are
		asked to write an explantion on the note. This is the longest, and most important aspect of the
		evaluation.
		& \\ \hline
		{\bf Debriefing} & 5 mins \\
		Users are thanked for their time and effort, and allowed to ask questions.
		& \\ \hline
	\end{tabular}
	\caption{Outline of co-design session.}
	\label{table:eval:cds:outline}
	\end{center}
\end{table}

\begin{figure}[h!]
	\centering
	\subfigure {\includegraphics[width=0.45\textwidth]{figures/eval/1.png}}
	\quad
	\subfigure {\includegraphics[width=0.45\textwidth]{figures/eval/2.png}}
	\quad
	\subfigure {\includegraphics[width=0.45\textwidth]{figures/eval/3.png}}
	\quad
	\subfigure {\includegraphics[width=0.45\textwidth]{figures/eval/4.png}}
	\caption{Groups of participants using the app and annotating the printed screenshots.}
	\label{fig:eval:codesign}
\end{figure}

%==============================================================================
% Results
%==============================================================================
\subsection{Results}
During each co-design session, participants were not told which aspects of the app to criticise. The purpose
of this was to see if any common themes emerged across groups. After the sessions, a thematic analysis was
performed on the post-it notes. This method of analysis is based in Grounded Theory, and goes against traditional
research methods which usually begin with a hypothesis.

Each post-it note was classified as \emph{Keep}, \emph{Lose} or \emph{Change} based on its colour. They were
then grouped in terms of which section of the app they referred to, and then which feature they referred to (if
applicable). Groups with more post-its were determined to be stronger themes. The following lists summarise the
strongest themes, the number in brackets being the number of post-its (e.g. (2) means 2 post-its). Some
suggestions which only had 1 post-it have been included in the summaries, particularly if they were also
a key talking point during the group discussions.

%==============================================================================
% - Keep
%==============================================================================
\subsubsection{Keep}

There were no strong themes emerging from the \emph{Keep} annotations. Participants generally complimented
aesthetic aspects of the user interface such as the layout, colours, icons and emoticons used. There were
some individual comments praising the daily calorie limit calculator, and the explanations and examples of
ingredients in the food diary.

\begin{itemize}
\item{General layout and colours (2)}
\item{Diary:}
	\begin{itemize}
	\item{Tabbed layout (2)}
	\item{Mood emoticons (2)}
	\item{Food category explanations}
	\item{Estimated daily calorie limit}
	\item{Template moods and emoticons}
	\item{Motivating progress bars}
	\end{itemize}
\end{itemize}

%==============================================================================
% - Lose
%==============================================================================
\subsubsection{Lose}

There was only one strong theme emerging from the \emph{Lose} annotations, and that was to remove the chunky
header in each of the Diary views.

\begin{itemize}
\item{Remove detail from Diary headers (3)}
\item{Ingredients for recording food}
\item{Mood diary feature}
\end{itemize}

%==============================================================================
% - Change
%==============================================================================
\subsubsection{Change}

The major themes all revolved around change, which is particularly useful as suggestions for change are
considerably more constructive than the other suggestions. There were general ideas such as adding support
for metric weights (kg), and more specific ideas for changing aspects of the Profile and Diary features.
These are summarised below.

\begin{itemize}
\item Support metric weights (5)
\item NumberPicker widget for recording weight not saving properly (4)
\item Support weight gain as well as weight loss
\item{Profile:}
	\begin{itemize}
	\item \emph{Before} and \emph{After} weights confusing (6)
	\item More concise or more exercise options (4)
	\item Show some idea of overall progress (3)
	\item Fit each page on screen to avoid scrolling (3)
	\end{itemize}
\item Diary:
	\begin{itemize}
	\item Change pencil icon to plus icon for \emph{Add} (6)
	\item Not allow user to see or record in future dates (4)
	\item Some way to distinguish today from other days (2)
	\item Multiple line limit when recording mood
	\item Graphs to visualise weight loss statistics
	\item Food:
		\begin{itemize}
		\item Not clear to long press food group for menu (6)
		\item Suggested foods (for keeping within limit)
		\item More segments for portion sizes
		\end{itemize}
	\item Exercise:
		\begin{itemize}
		\item Choose from a selection rather than typing (6)
		\item Progress bar should explicitly say `Minutes' (2)
		\item Enter number of calories burned
		\item Be able to record exertion
		\end{itemize}
	\item Photo:
		\begin{itemize}
		\item Tab icon should be a mirror instead of camera (4)
		\item Image didn't always appear immediately (2)
		\end{itemize}
	\end{itemize}
\end{itemize}



%==============================================================================
% Reflection
%==============================================================================
\subsection{Reflection}
Having had time to reflect on using co-design as a methodology for software evaluation, there are some notable
issues which have arisen retrospectively. In general, the method has proven to be very successful, rich
qualatative data was gathered, and was used to make direct changes to the app in the subsequent iteration.

%==============================================================================
% - Honesty
%==============================================================================
\subsubsection{Honesty}
Several participants `apologised' after the workshops for some of the comments they left during the
Keep/Lose/Change exercise. This suggests that participants were perhaps more honest when leaving written feedback
than they would have been in an interview. Honest feedback is better than feedback `they think we want to hear', particularly for a user centered project such as this.

%==============================================================================
% - Non Graphical Features
%==============================================================================
\subsubsection{Non Graphical Features}
During each group discussion, there was usually some mention of the \emph{refresh} Diary feature, which utilises
the accelerometer. Unfortunately, this theme did not arise from the Keep/Lose/Change exercise. This was probably
due to the non graphical nature of it; perhaps participants didn't feel prompted to leave any comments
about it because there were no screenshots `displaying' this feature for them to annotate. Any non graphical
element such as this would need to be taken into account for future co-design workshops.

%==============================================================================
% - Demographics
%==============================================================================
\subsubsection{Demographics}
The demographics were limited by the availability of participants. All 12 participants were undergraduate
computing science students (10 male, 2 female; aged 19-24). The feedback has been particularly useful, not in
spite of this, but because of this.

Participants were possibly unwittingly considering issues such as relevance to the project. For example, nobody
complained about Android's software keyboard, despite several users being exposed to it for the first time.
Perhaps they didn't complain about this because they were aware it was a variable outwith the project's control.
It would have been interesting to have run a session with non technical participants, to see if any new themes
emerged.



%==============================================================================
% B E T A   T E S T I N G
%==============================================================================
\section{Beta Testing}

%==============================================================================
% Aims
%==============================================================================
\subsection{Aims}
During the third iteration of development, significant changes were made to the app based on feedback from the
co-design sessions. This summative evaluation aimed to gain both qualitative and quantitative subjective feedback
from users who were actually using the app in their own environment. Often, issues which arise in situ cannot be
found in short term laboratory settings. It is these long term issues that this evaluation aims to identify.

%==============================================================================
% Methodology
%==============================================================================
\subsection{Methodology}
10 participants were paid \textsterling15 to use the app for 7 days on their own device. During this time,
participants were emailed tasks to perform, as shown in table \ref{table:eval:bt:outline}. Users were encouraged
to self-report their progress using the \emph{Feedback} feature of the app.

Over the course of the week, small changes were made to the app based on the feedback from participants.
These were then pushed to the users' devices in the form of updates, following a more agile development
approach. These updates also unlocked new features of the app, such as the \emph{Community} feature.

This type of evaluation is often described as \emph{in the wild}, as participants are self-reporting on their
usage of an app from their own device and in their own environment. Users were asked to assume the mindset of
someone wishing to lose weight, and to use the app as often as they wished to complete the tasks. No data was
logged, as the app could contain personal data (weight, feelings), and participants may have used the app
differently if they believed there was a chance that their activity was being monitored.
%https://doc.novay.nl/dsweb/Get/Document-100602

7 of the 10 participants had previously taken part in a co-design workshop as discussed in chapter
\ref{eval:cds}. They were encouraged to give feedback on any noticeable differences between the new version
and the version they used in the workshop.

After using the app for a week, participants were asked to complete an online questionnaire. The questions
were a mix of closed and open questions, which were used to gain subjective feedback on usability aspects of
the app. Two focus groups (N=3; N=2) were also run after the week, to gain further insight into the participants'
experience, and how it could have been improved upon.

\begin{table}[!ht]
	\begin{center}
	\begin{tabular}{| p{12cm} | c |}
		\hline
		{\bf Task 1} & Prepare \\
		\begin{itemize}
		\item Download the app
		\end{itemize}
		& \\ \hline
		{\bf Task 2} & Days 1-3 \\
		\begin{itemize}
		\item Set up a profile
		\item Become familiar with the main areas of the app
		\item Use the Diary on a daily basis
		\item Use the Feedback feature when necessary
		\end{itemize}
		& \\ \hline
		{\bf Task 3} & Days 4-5 \\
		\begin{itemize}
		\item Update to latest version
		\item Continue to use the Diary as normal
		\item Take pictures of some foods
		\item Use the Inspiration feature
		\item Use the Feedback feature when necessary
		\end{itemize}
		& \\ \hline
		{\bf Task 4} & Days 6-7 \\
		\begin{itemize}
		\item Update to latest version
		\item Investigate Community feature
		\item Investigate Help Requests feature in Food Diary
		\item Continue to use Diary/Inspiration/Feedback as normal
		\end{itemize}
		& \\ \hline
		{\bf Task 5} & Finsih \\
		\begin{itemize}
		\item Use the Feedback feature to send a brief `final note' on your experience
		\item Fill in the questionnaire
		\item Arrange to join a focus group
		\end{itemize}
		& \\ \hline
	\end{tabular}
	\caption{Outline of beta testing week tasks.}
	\label{table:eval:bt:outline}
	\end{center}
\end{table}

%==============================================================================
% Results
%==============================================================================
\subsection{Results}
The app was released to Google Play (formerly the Android Market) on the 28th of February 2012. The 10
participants were sent the first of their tasks, and asked to begin the evaluation. This beta version of the
app was made public, and over the course of the week, was downloaded on 21 devices, meaning the app was also
downloaded by users who were not participants. Despite this, there were only 2 uninstalls, and all users
actively updated the app, suggesting that real end users were using the app. Figure \ref{fig:eval:devices}
shows the distribution of devices with the beta version installed.

\begin{figure}[h]
	\centering
	\includegraphics[width=0.8\textwidth]{figures/eval/devices.png}
	\caption{Devices which had the beta version installed on them.}
	\label{fig:eval:devices}
\end{figure}

%==============================================================================
% - Self-reporting
%==============================================================================
\subsubsection{Self-reporting}
The majority of users sent feedback using the self-reporting Feedback feature of the app. Over the course of the
week, 20 reports were received, which included how the app was being used, ideas for improvement, and bug reports.

%==============================================================================
% -- Usage
%==============================================================================
Several participants sent feedback detailing how they were incorporating the app into their lives. This feedback
was usually in the form of short sentences explaining a particular scenario in which the app was being used.
This is useful, as it gives a good insight into what the user is doing when using certain features.

\begin{quote}
\emph{``I dropped my Wispa Gold wrapper in the bin without checking the calories. I put it on the community to
ask for help.''}
\end{quote}

As the example above illustrates, these scenarios can be used to help design for usability in future iterations.
Users could be prompted to ask the community for help any time are unsure of the number of calories when 
recording food in the food diary.

\begin{quote}
\emph{``I mostly use the app at night after dinner. I'm using it on my tablet rather than my phone so it's
usually the only time I get to use it. I like the quick add feature, because my meals are quite regular. I notice
that this leads to it having quite a lot of duplicate entries, especially since I have a turkey sandwich every
day. Could maybe have it scan for duplicates when it adds to quick add list, or mark food as being `new' or `from
quick add' so that they aren't re-added. It looks good on a big tablet screen. I blame my girlfriend's delicious
saturday grilled brekkie for today not being the healthiest of days :P''}
\end{quote}

As well as short scenarios, some participants gave thorough explanations of when and how they were using the
app. As the passage above descibes, this user mostly used the app at the same time each day. Again, this
feedback can also be used to guide future iterations of development. This passage also suggests that the newly
added `quick add' feature for the food diary has been particularly useful. This was implemented due to direct
feedback from the co-design workshops, and appears to have been well received. The user also said the app looks
good on a tablet device, confirming that the app scales well on larger screen sizes.

%==============================================================================
% -- Improvement
%==============================================================================
During the course of the week, many participants reported suggestions for changing aspects of the app.

\begin{quote}
\emph{``Any chance you could cache content from the suggestions section? It's loading every time you open the
list, even when you hit back from one of the suggestions.\\
\\
Also notifications that you have pending suggestions would be good.''}
\end{quote}

This user noted that pages in the Community feature were refreshed when reloaded, and suggested that previous
results should be cached until the user presses `refresh'. They also suggested that users should be given
notifications when another user replies to their request with a suggestion.

\begin{quote}
\emph{``Thought I'd mention, it would be nice to know exactly what a `good' goal date is. I'm sure it's dependent
on the person, but perhaps you could have a little guide. Is the automatic date a good guess for the weight you
enter?''}
\end{quote}

Most users were curious to know how the `recommended weight' was caluclated. The initial design was to hide the
complexity of the calculations from the user. However, the feedback suggests that users would prefer to know
how these values and dates are calculated. This can be taken into account in subsequest versions.

\begin{quote}
Just a couple of points: whenever i have to input text, because i'm using a 7" tablet the entry box goes off the
screen. Would be fine if i could scroll the box down into view. Also, for the ingredients, you dont have a option
for a full item, i.e. 2 slices of bread has to be inputed twice. A quantity specifier would also be useful.
Finally it would be great to be able to specify a calorie count if known for items not under "other", i.e. if i
knew the calorie count for the bread i was eating.
\end{quote}

The above report explains that aspects of the Feedback feature were not ideal for using on a tablet. After
investigating, it turned out that the initial beta version restricted self-reports to be on a single line of
text. This was quickly changed, and the updated version of the app was pushed to the participants' devices.

Several users also noted that the portions sizes were too small. They suggested that they were underestimating
the number of calories in a food simply because there was no \emph{extra large} portion size to choose from. One
participant suggested that there should be a way to specifiy quantity (ie. \emph{2} slices of bread), to
avoid the repetitive re-adding of items, or the need for larger portion sizes.

%==============================================================================
% -- Bugs
%==============================================================================
Participants were very quick to find bugs, the majority of bug reports were sent within the first few days.
In all cases the defects were identified and fixed, and an update was pushed to the participants' devices.

\begin{quote}
\emph{``I've found a bug where when I choose a red food, an orange one appears. Screenshot is attached.''}
\end{quote}

\begin{quote}
\emph{``The red entered as an orange item.''}
\end{quote}

\begin{quote}
\emph{``Hey, just noticed that when you add something from the treat pop up menu it adds it as the orange pie
chart and lower calories.''}
\end{quote}

\begin{quote}
\emph{``calorie calculations don't seem correct. 3/4 red is 450cal but after saving it totals as 600cal''}
\end{quote}

\begin{quote}
\emph{``Ok so I had lasagne for dinner and I decided to fill in the calories. I long held on the purple category
and clicked on the grey circle after the explanation came out. That actually doesn't enter the grey circle
properly. Instead it shows a grey circle and asks only for a name, not for the number of calories.''}
\end{quote}

The five reports listed above were all received within the first 2 days of the evaluation. They refer to several
bugs related to recording food. Again, these were quickly addressed, and the updated version was pushed to
participants' devices. There were no bug reports related to recording food after the update.

\begin{quote}
Few bugs:\\
\\
It has added previously used (unrelated) images to items in my quick add list.\\
\\
When I accidently added something then removed it, the item still appeared in quick add.
\end{quote}

Although users generally praised the new `quick add' feature, participants reported some bugs. One bug was the
result of Android's \begin{verbatim}ListView\end{verbatim} reusing old views for memory optimisation. Some food
records do not have an associated picture (the user didn't photograph the food). If the
\begin{verbatim}ImageView\end{verbatim} for this \begin{verbatim}ListView\end{verbatim} item is not explicitly
set to \begin{verbatim}null\end{verbatim}, it could show an image from a previous food record. This is because
the \begin{verbatim}ListView\end{verbatim} was reusing a view which previously displayed a food record with a
picture.

\begin{quote}
My bowl of Frosties came out as ``Food'' today when I turned image recognition on. So disappointed.
\end{quote}

The beta version introduced the new auto-naming feature of the food diary. Rather than type in the name of the
food they are recording, the user can take a picture it and the app will try to identify the picture using an
image recognition web service. 37 image recognition requests were made over the course of the week. The majority
of the images were identified correctly, however there were a few exceptions. Some participants complained that
the request returned ``food'' or ``drink'' or a colour such as ``red'' or ``white''. The most successful requests
were ones which contained a brand or logo, such as ``Coco Pops'' or ``Mackay's Jam''. %TODO Appendix

\begin{quote}
How do I delete a help request?
\end{quote}

Another new feature introduced in the beta version was the internal Community, which allows users to ask for help
when adding to their food diary by sending a request. A bug was reported when a participant tried to delete a
request he had made, but then cancelled half way through. The request was deleted from the local database on his
device, but \emph{not} from the remote database. This resulted in the request being left permanently on the
remote database, with no way for the user to remove the request or accept any suggestions for it. To fix this
issue, all steps needed to delete the request would need to be made atomic.

\begin{quote}
Hey, I've been taking pictures of foods and a problem I noticed was pictures disappearing if the phone switches
from landscape to horizontal view.
\end{quote}

One issue that arose was a problem with screen orientation. When users change their device orientation from
portrait to landscape (or vice versa), the current activity restarts. This is an Android convention, but can
be problematic in cases where users are in the middle of a task, and the activity is effectively reset. This
can be fixed in two ways; save the state and use this when restarting the activity; disallow activities to
restart when 

%==============================================================================
% - Questionnaire
%==============================================================================
\subsubsection{Questionnaire}

%==============================================================================
% - Focus Groups
%==============================================================================
\subsubsection{Focus Groups}

%==============================================================================
% S O F T W A R E   V E R I F I C A T I O N
%==============================================================================
\section{Software Verification}
With Cindy bla...





%==============================================================================
%
% C O N C L U S I O N
%
%==============================================================================
\chapter{Conclusion}
\label{conc}



%==============================================================================
% S U M M A R Y
%==============================================================================
\section{Summary}
Summary...



%==============================================================================
% F U T U R E   W O R K
%==============================================================================
\section{Future Work}
Bla...



%==============================================================================
% L E S S O N S   L E A R N E D
%==============================================================================
\section{Lessons Learned}
Bla...





%==============================================================================
%
% A P P E N D I C E S
%
%==============================================================================
\appendix



%==============================================================================
% A P P E N D I X   1
%==============================================================================
\chapter{Appendix 1}
\label{appendix:ppqnaire}



%==============================================================================
\bibliographystyle{plain}
\bibliography{l4proj}
\end{document}
